Most Internet data applications today use reliable transport protocols, such as the transmission control protocol (TCP), which have been tuned for traditional networks comprising wired links and stationary hosts. TCPs assume congestion in the networks to be the primary cause for packet losses (packets can contain thousands of bytes of data) and unusual delays. Congestion occurs when the primary requirements of source(s) exceed the transport capability of a network node. For example, where multiple senders transmit packets to a network node faster than the node can forward the packets the buffer may overflow resulting in congestion, and some of the received packets can be lost. Congestion may also be defined as the condition that exists when the network node buffers occupancy is greater than some threshold.
The TCP protocol controls congestion by utilizing acknowledgements from the receiver and adjusting a sliding window for the sender. The sender will not be able to transmit packets beyond the window size. Upon receiving the acknowledgements from the receiver the window slides ahead and gets incremented. As long as there is no loss, the window size is gradually increased. When a loss occurs, the window size is reduced and then slowly expanded. The sender can identify that a packet has been lost due to congestion either by the arrival of duplicate acknowledgements indicating a loss or by the absence of receiving an acknowledgment within a timeout interval. This entire process of controlling the window size to limit congestion is known as a “congestion control mechanism.”
When acknowledgements fail to be received by the sender for reasons other than congestion, however, congestion compensation measures, such as reducing the window size, can result in unnecessary reduction in end-to-end throughput and suboptimal performance. Today Internet and wireless communications links are increasingly being used to transmit data packets in applications such as email, web browsing, mobile computing, and other such applications. Most of these applications make use of reliable end-to-end transport level services provided by TCP. TCP was designed for networks where congestion is the primary cause of packet loss. However, transmission errors over wireless links such as due to fading may often lead to packet loss. Thus, the loss of packet may be due to reasons other than congestion. Wireless links often suffer from sporadic high bit-error rates (BERs) and intermittent connectivity problems due to handoffs. Consequently, TCP performance in networks having wireless links suffers from significant throughput degradation and very high interactive delays due to unnecessary use of congestion compensation mechanisms.
There are currently two approaches to improve TCP performance in such lossy links. A lossy link is a link where packet losses are due to high BERs rather than congestion, such as a wireless link. The first approach hides any non-congestion-related losses from the TCP sender, and therefore requires no changes to the existing sender implementation. The approach assumes that, since the problem is local, it should be solved locally, and that the transport layer need not be aware of the characteristics of the individual links. The lower layers of the network solve this problem by local retransmissions. Protocols adopting this approach attempt to make a lossy link appear to be of a higher quality at the cost of a reduced effective bandwidth. As a result, most of the losses seen by the sender are apparently caused due to congestion, thus reducing performance due to unwarranted invocation of the congestion control mechanism.
The second approach attempts to make the sender aware of the existence of lossy segments, by indicating to the sender that some packet losses are not due to congestion. There are currently two methods using the second approach. The first method uses an end-to-end scheme named EE2E-ELN protocol. This scheme improves TCP performance in lossy networks by making the sender aware of the lossy link. The scheme adds Explicit Loss Notification (ELN) options to TCP acknowledgements. The problem with this scheme is that the Link Layer (LL) is involved in detecting packet losses. This is not desirable because it violates the modular structure of a TCP/IP suite. In addition, adding ELNs to TCP acknowledgements is not yet recommended by the Internet Engineering Task Force (IETF).
The second method uses a scheme, that uses the difference between Round Trip Time (RTT) of the last correctly received packet and the previously received packet, along with notification from the receiver about a packet loss, to determine the cause of the packet loss. The problem with this scheme is that it uses the difference between RTTs to find out reasons for a packet loss. For the scheme to be effective, RTT has to be precisely calculated. Because highly accurate clocks have to be used, it is impractical to implement this scheme in real-time applications. Therefore, there is a need in the art for a technique that improves TCP performance in lossy networks, such as wireless communication networks with congestion compensation mechanisms, that is computationally efficient and practical to implement.